Enqueue and PromoteJob have both used ZADD XX GT since #3 to preserve
the deferral guarantee for jobs enqueued with deterministic IDs: once a
schedule sits at time T in the future, a duplicate enqueue at T' < T
must be a no-op, and PromoteJob must not demote a job whose score has
been bumped to now + InvisibleSec by Dequeue. That is the right
semantic for dedup-style jobs that may race their own re-enqueue.

It is the wrong semantic for two cases that have grown up around the
queue since:

1. Worker retry rescheduling. When a handler returns an error the
   retry middleware computes a backoff delay and calls Enqueue with
   score = now + delay. With GT, that score is rejected because the
   Dequeue invisibility mark (now + InvisibleSec, typically 60s) is
   greater. The configured Backoff is effectively dead for any value
   less than InvisibleSec; gated handlers re-run only on the
   InvisibleSec cadence regardless of how short the backoff is.

2. Subqueue PromoteOnAck. The subqueue middleware advances the next
   gated job after the prior handler Acks by calling PromoteJob on
   that job's ID. With GT, the score (still sitting at the
   InvisibleSec mark from its last dequeue/gated cycle) is also
   rejected and the next job continues to wait out its full
   invisibility window.

Add a per-job AllowPromotion flag. Default false preserves today's GT
semantics so dedup-deferral jobs are unaffected; setting true causes
Enqueue to use plain ZADD XX so backoff can lower the score, and
causes PromoteJob to use ZADD XX (without GT) so the next gated
subqueue entry can be advanced. The flag is read only after the job 
is initially enqueued. 

The Enqueue Lua script splits the per-job arg list into two ZADD
calls (one with gt, one without) so a mixed BulkEnqueue stays atomic.
PromoteJob does an HGET to read the flag before issuing the ZADD;
this adds one round-trip per promotion but keeps the API stable.